Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker"

Date de la création de cette note : 2024-06-05.

Ce projet est terminé : voir 2024-07-06_1116.

Quel est l'objectif de ce projet ?

Bien que j'aie beaucoup travaillé de décembre 2023 janvier 2024 sur le projet Implémenter un POC de pgBackRest, je souhaite mettre à jour et améliorer le repository restic-pg_dump-docker.

Quelques tâches à réaliser :

[x] Mettre à jour tous les composants ;
[x] Publier le Dockerfile de stephaneklein/restic-backup-docker ;
[ ] Réaliser et publier un screencast ;
[x] Améliorer le README.md.

Pourquoi je souhaite réaliser ce projet ?

Pourquoi continuer ce projet alors que j'ai travaillé sur pgBackRest qui semble bien mieux ?

Pour plusieurs raisons :

Je ne peux pas installer pgBackRest dans un « sidecar container Docker » — en tout cas, je n'ai pas trouvé comment réaliser cela 🤷‍♂️. Je dois utiliser un container Docker PostgreSQL qui intègre pgBackRest.
Pour le moment, je ne comprends pas très bien la taille consommée par les "WAL segments" sauvegardés dans les buckets.
Pour le moment, je ne sais pas combien de temps prend la restauration d'un backup d'une base de données d'une taille supérieure à un test. Par exemple, combien de temps prend la restauration d'une base de données de 100 Mo 🤔.
Je ne suis pas rassuré de devoir lancer un cron — supercronic — lancé par tini

Bien que pgBackRest permette un backup en temps "réel" et est sans doute plus rapide que "ma" méthode "restic-pg_dump", pour toutes les raisons listée ci-dessus, je pense que la méthode "restic-pg_dump" est moins complexe à mettre en place et à utiliser.

#JeMeDemande si la fonctionnalité "incremental backups" la version 17 de PostgreSQL sera une solution plus pratique que pgBackRest et la méthode "restic-pg_dump" 🤔.

Repository de ce projet :

https://github.com/stephane-klein/restic-pg_dump-docker

Je vais travailler dans la branche nommée june-2024-working-session

Journaux liées à cette note :

Je pense avoir terminé le projet Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker".

Merci à Alexandre pour ses commits de GitHub Actions CI/CD et du support multi architectures publié sur Docker Hub : # stephaneklein/restic-pg_dump.

Je suis assez satisfait du résultat. Le projet a été réalisé avec soin et j'ai tenté de le simplifier au maximum.
Il reste cependant une dernière possibilité de simplification à implémenter : Suggestion : Remplacer Supercronic par Cronie.

Bilan du temps passé sur le Projet 7 :

8 sessions de travail entre le 5 juin et le 6 juillet 2024 ;
Pour un total de 10h16.

Nouvelle #iteration sur Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker".

Alors que je travaille sur cette partie du projet, je relis la documentation de pg_dumpall et je constate à nouveau que cette commande ne supporte pas les différents formats de sortie que propose pg_dump 😡.
C'est pénible… du coup, j'ai enfin pris le temps de chercher si il existe une solution alternative et #JaiDécouvert pg_back :

pg_back is a dump tool for PostgreSQL. The goal is to dump all or some databases with globals at once in the format you want, because a simple call to pg_dumpall only dumps databases in the plain SQL format.

C'est parfait, c'est exactement ce que je cherche 👌.

Mais je découvre aussi les fonctionnalités suivantes :

Pre-backup and post-backup hooks

Purge based on age and number of dumps to keep

Dump from a hot standby by pausing replication replay

Encrypt and decrypt dumps and other files

Upload and download dumps to S3, GCS, Azure or a remote host with SFTP

Conséquence : #JeMeDemande si j'ai encore besoin de restic dans Projet 7 🤔.

Je viens de lire ici :

In addition to the N previous backups, it would be nice to keep N' weekly backups and N'' monthly backups, to be able to look back into the far past.

C'est une fonctionnalité supporté par restic, donc pour le moment, je choisis de continuer à utiliser restic.

Pour le moment, #JaiDécidé d'intégrer simplement pg_back dans restic-pg_dump-docker en remplacement de pg_dumpall et de voir par la suite si je simplifie ce projet ou non.

Nouvelle #iteration sur Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker".

Hasard du calendrier, mon ami Alexandre travaille en ce moment sur un projet nommé restic-ftp-docker.

Quelle différence avec restic-pg_dump-docker ?

Principale différence d'objectif entre ces deux projets :

restic-ftp-docker sauvegarde via restic le contenu d'un dossier vers un espace FTP.
restic-pg_dump-docker sauvegarde via restic le contenu d'une base de données PostgreSQL. Le contenu de la base de données est exporté avec la commande standard pg_dump de PostgreSQL. La sauvegarde peut être envoyée vers tous les storages supportés par rclone.

#JaiDécidé de reprendre un maximum d'élément du projet restic-ftp-docker dans restic-pg_dump-docker.

#JeSouhaite proposer une Pull Request à restic-ftp-docker pour étendre ce projet à tous les storages supporté par rclone et ne plus le limité au storage ftp.